2.2 Developing Composite Applications: Application Assembly

Notes/Domino 8 Forum

Subject:

2.2 Developing Composite Applications: Application Assembly - Part 1

Designing Composite Applications: Composite Application Assembly - Part 1
Jo Grant, Craig Wolpert

Prerequisites:
Review Chapter 1 from Composite Applications Toolkit User’s Guide.
Review the Composite Applications Tutorial

Intro
Composite applications are a key element in a service-oriented architecture (SOA) and contextual collaboration strategy. They support business flexibility for companies and organizations who wish to rapidly respond to changing demands in today's competitive markets. Composite applications are aggregations of user interface components that are loosely coupled to support inter-component communication. Components can be reused in multiple composite applications. The ability to combine multiple technologies into a single application provides significant business value. It enables companies to protect and extend their existing assets with increasing degrees of flexibility, and to respond quickly and cost effectively to their emerging business requirements, with applications that are significantly easier to create than multiple application development environments.

This loose coupling of the Composite Application Architecture also enables diverse groups in different locations to leverage each others efforts and to interoperate with each other. For example, one department may be working on the accounting application for a company while another group is working on a Sales Lead Tracking Application. The Composite Application vision is that it would be possible to add into the accounting application some components from the sales lead tracking application to give pertinent views of assets in an accounting context. Similarly the sales lead tracking application could incorporate components from the accounting application to give accounting information within a sales lead context. As your company develops more and more composite applications, the potential for integration increases exponentially. The goal is that the whole is greater than the sum of the parts.

The composition application model is already familiar to IBM(R) WebSphere(R) Portal developers. This approach has been extended to Notes version 8, enabling Notes developers to surface their Notes applications as one or more components in a composite application. IBM(R) Lotus(R) Domino Designer(R) has been extended to leverage the property broker, as well as to provide a more intuitive user environment. Notes version 8 also supports the inclusion of Eclipse components and a composite application may have any combination of Notes components and Eclipse components. These may be just be presented together in the same UI for on the glass integration or if extended to use the Property Broker will fully be able to interoperate with each other. You can define composite applications using the Composite Application Editor (CAE) or the WebSphere Portal Application Template Editor.

One of the great advantages of the loose coupling of Composite applications is that application assembly can be conducted much later than component creation and design. It can also be done by the subject matter experts who will either be using the application or who are very close to those who are. This article discusses some general design tips and techniques that you can use to assemble highly productive and compelling applications.

This is the first article of a two part series covering aspects of application assembly. In this one we consider Page Design, and Navigation. In the second one we consider Designing For Change, Wiring Strategies, and how to Prototype Layout.

Page Design
Page design has two major goals: to bring together all of the functionality needed to perform an operation, and to present all the information necessary in order to make that operation easy and intuitive. In a perfect world we could arbitrarily move about the visual information we have into the exact configuration we desire. This can be done in traditional application development, but it is a highly technical job and incorporating cross domain information is not an easy task. Composite application assembly is a much simpler task where information is easy to present no matter what the domain. However there are some trade offs in how we can present that information.
Scope of Components
At its most fundamental level a component in a composite application is a rectangle of screen. What is displayed in that rectangle is defined by the component. This is the smallest unit of granularity we can manipulate in composite application assembly. We cannot normally choose to only display certain information in a component, or to display information from one component in another one. However components are rarely static. When assembling a component into an application you have two options for controlling how the component presents things.
Firstly properties may be set on the component itself, You do this in the CAE by right clicking on a component (e.g. Sales Lead Browser, below) on the component tree and selecting "Edit Component Properties". The Edit Component Properties dialog box gives you a few options to set on the component. The Advanced Component Properties dialog box shows many more. Consult the documentation provided with any particular component to see what settings can be made to it. The illustration below shows the Sales Lead Browser component which supports database.server and database.replicaid settings with which you can specify the database used to find the data to display.

Secondly most components support a number of properties that report values and actions that consume them. These are the arteries and veins that promote your composite application from a series of independent windows to an integrated whole. The documentation on each component will list the properties it publishes and the actions it consumes, the values for these, and the effects that setting them has. Each action or property has a type associated with it. To prevent errors, you can only wire properties to actions which have the same type. Such strong typing can occasionally be an issue at assembly time. It may be that components from one source use a PartNumber type while components form another source use a PartNum type. The values they represent may be identical, but they can not be wired because they have different types.
The opposite problem may also occur.There is a generic "string" type that can be used for general cases. Some components may be produce with all of their properties and actions of this type. Without the type checking you can wire anything to anything, even if it makes no sense. For example, you could wire a CustomerName to a PartNumber. The documentation for the originating property and the consuming action should be consulted to make sure the combination will function as expected.

In the diagram below you can see how the LeadDetail component is wired on the Lead page of the Lead Manager sample application. To see the wiring, right-click on the LeadDetail component and select "Wiring" in the CAE. In this example, the "Contact" property is selected in the LeadDetail component. It is a plain text property and can be wired, as indicated, to a wide variety of other actions. Only certain ones make sense. Consulting our documentation, we find out that the Column Filter action in the Discussions, Contracts, and Sales Lead Company Detail components all accept a plain text value, but they are for categorizing views that are not applicable for a contact value. However the Contact name, Schedule A Meeting and Send Mail actions also accept a plain text component and do expect a value in the form of a contact, so those would be valid wire destinations.

Basic Layout Patterns
A page in a composite application is generally focused on getting a specific task done. It can be divided, in general, into components that you use to accomplish the task (domain centric components, for example a component that lets you edit a record), and components that help you to accomplish the task (contextual domain components, for example, a component that lets you search cost centers). The most functional grouping is to locate the domain centric components together in the center stage of your page. The contextual domain components are then arrayed around the periphery like a dashboard.
The pages of the Lead Manager application use this general layout where the areas enclosed by a red box are the domain centric components on each page:

In each example, the work area (containing the domain centric components) is prominent and the additional areas (containing the contextual domain components) provide contextual information.

Getting More out of your Pixels
Screen real estate disappears fast. There may be any number of contextual components that would add value to an operation, but how do you add them in such a way that is not crowded and cluttered? The object is to enhance the work experience, not overwhelm the user. Fortunately there are a few things that help provide more in a manner suitable to the user.
Tabbed Folders. Instead of adding a component to a fixed rectangle on the screen, you can add it on top of another component. These components will combine to create a tabbed folder. Each component gets slightly less space, since there needs to be room for the tab bar, but as you tab between them they get all of the space available. This is a good way to present a number of components with mutually exclusive information on them. The user can pick which one makes sense to view for the aspect of the operation they are conducting. It is also possible to programmatically focus tabs in a folder, for greater automation.
One particularly nice aspect of folders is that they are easy to extend. If another component is developed later that needs to be added, this can be done so with minimal disturbance by using folders. Wide horizontal tabbed folders work better than narrow vertical ones for tabs, since it allows for greater expansion of tab names.
Maximize/Minimize. Components can be maximized or minimized by user or program action. When maximized, the component takes up the full screen real estate. A contextual domain component can become a domain centric component with one click. For example in the Lead Manager application a Managed Browser component is added to a tabbed folder to view a company's web page. For the size given, it is of limited use. However the user can easily maximize that component, view the web page for the information needed, and then restore it to its original folder size to continue working .
Pop up components. A style of component presentation is to have minimal UI for a component until triggered. The trigger can be a property firing, the minimal UI being clicked (e.g. a button), or some other event. When triggered, a dialog box pops up with the additional information in it. The dialog box can be modal, for fixed information that has to be actioned, or modeless, if the user needs it to remain on the screen for reference.
Shelf View. The Lotus Notes V8 desktop already comes with a side shelf with views in it that persist across applications. It is possible to make additions here visible and invisible programmatically. You can deploy your own UI in this space. You can highlight items or control their visibility in this space depending on whether the functions are always needed or are application specific.
User resizing. Perhaps the ultimate method of customization is letting the user take control. You can make components of fixed size, or you can allow them to be dynamically resized by the user. If you fix the size in the CAE, it will remain (proportionally) the same for all users independent of screen size. If you let the user adjust it they can change the relative sizes to suit their monitor and usage. Their changes will persist for them and no one else.

Navigation Design
A composite application is rarely limited to a single page. A page is a good unit for focusing on a particular data item or a single task. But most often the information domains we work in span several data types and have complex or multiple tasks. The natural evolution from a page as an organizational unit is to a multi-page application as a unit. But once our UI grows to more than a single page, we start having to make design choices to move the user from one page to another. There are several choices.
User Selection Driven. In this model all the pages of an application are available for the user to choose from. A common navigator will be present to allow a user to make a choice of which page to view at any time. This could be the built-in composite application navigator which appears as a column to the left of the screen or it could be a custom control that presents a list of buttons with drop down options. This model works well in a composite application that has been built with the aggregation model discussed in the Composite Application Design Patterns article. Context in one part of the application is not used or determined by another part, so the work process is not interrupted by transition at any time.
User Process Driven. This model is similar to the "wizard dialogs" in applications. The user experience starts at a certain "on ramp". As tasks are completed on a particular page, the workflow moves the focus to another page. All navigation is done programmatically. The user does not explicitly navigate from page to page. Instead the pages move to support the completion of each task. This works well for process centric applications. Much as a page concentrates on helping the user to fulfill a task, an application then guides the user through an operation; a series of tasks.
Multi-tab or single tab. In many circumstances the default Notes behavior is to launch a new context in a separate high level tab. This is a familiar model for existing Notes users, but in Lotus Notes 8, such a new high level tab cannot be a page from a composite application. Composite application pages have the advantage of being able to add a number of other components of use to the operation Sometimes tasks may need to be conducted in parallel and need to be on their own tab. Still others can be sufficiently focused that there is no benefit of additional components. You need to choose what best suits the operation being conduced.
In the Lead Manager sample each type of tab is used in different areas. When viewing the details of a sales lead, you are presented a composite application page under the main tab. Additional components are there to guide your experience. However, when composing a response to a sales lead discussion, a new tab is created that contains just the response form. It can be filled in then, or later, depending on the user's process.
Hybrid. There are a number of possibilities between these two approaches. It may be that an application is mostly programmatically driven, but that there are several "on ramps". Initially the application might appear as user selection driven with a subset of the pages that the user can navigate. Once the starting position is selected, the process is engaged and the general navigation may disappear, leaving them in process driven mode. When complete, the user may be returned to a position where they can pick another starting point.
The Lead Manager example used a version of the hybrid approach. A common navigation bar is present showing three possible "on ramps": Leads, Companies, and Contacts. Once an item is chosen, the user is brought to another page not otherwise accessible. For example, a user can double click a lead from the Leads page which programmatically navigates to a Lead Detail page which is not accessible from the navigation bar. The high level navigation bar is still available, though, and the user can move from that context back to an on-ramp context.

Navigation Implementation
There are a number of ways to implement your navigation design choice in a composite application.
System Navigator. A built-in navigator is provided as part of the Notes composite application platform. This allows you to switch between the pages of a composite application. A tree view appears on the left-hand part of the page when the system navigator is enabled, which is the default state. The system navigator is controlled by the Root page preferences: com.ibm.rcp.useNavigator and com.ibm.rcp.navigationModel. You can arrange your pages into a hierarchy that a user can navigate in any manner, at any time. You can choose which pages to display. Note: unsaved Notes documents will prompt the user to save changes when the user moves on to another page.
The system navigator has the advantage of being already present and deployed. Configuration of pages for use with the system navigator is supported directly in the Composite Application Editor. If used in several composite applications, the system navigator will give a common look and feel to your users. Drag and drop is supported across multiple pages. (If you drag starting from one page, and hover over another page in the navigator, you can drop on to that page.) However you do not have any additional design choices for this navigator. You cannot change it's position, size, or color.
Custom Navigator. It is possible to create a custom navigator that has a look and feel that supports your workflow. This allows you to programmatically discover the pages in an application, and to switch between those pages. The Lead Manager sample application uses such a custom navigator. The options displayed are driven by properties set on the custom navigator component. However such a component must be created or otherwise acquired. It needs to be deployed with the rest of your application and, most likely, will not support drag and drop.
Cross Page Wires. Typically wires are used to connect a property of one component to an action on another component. Information is propagated across a page in this manner. However wires can also be created between components on different pages. When this is done the data is not only conveyed, but the application is switched to the new page. This allows a page navigation model to be developed from the actions that a user takes while using the application. It works well for the user process driven model. You can create a "navigatorless" application design using this.
In the Lead Manager sample many of the components broadcast when a data element is selected, but also when it is double clicked. Selection is used frequently in wiring strategies and is wired from the originating component to the peripheral components to show state. The double click property is used to trigger page transitions by using it in a cross page wire and is less frequent. The wire is connected to an action in a domain centric component on the new page and carries with it a page transition, as well as the context that the new page is to focus on.
Workspace Launcher. Composite Applications or pages can be listed on the workspace launcher. This can be set on the application and page properties dialogs. These then appear under the Open button in the Notes 8 client. For deployment purposes you may wish to bundle several functional areas into a single composite application. This is one way to surface several "on ramps" into your composite application and should be considered along with navigation design and implementation.

Conclusion
In this article we discussed tips and techniques for creating pages, and methods of moving from page to page. Page design and layout is critical for all application. Navigation design becomes important as the number and size of components will not fit on a page, or the application contains multiple tasks or processes. Composite application assembled correctly can increase productivity but the inverse is also true. The second article in this series covers Designing For Change, Wiring Strategies, and how to Prototype Layout.

Feedback response number JGRT77URHU created by ~August Umtumitherader on 10/10/2007